home *** CD-ROM | disk | FTP | other *** search
/ PD Collection CD 1 / PD Collection CD 1.iso / textual / keychang / !KeyChange_ProgInfo < prev   
Encoding:
Text File  |  1992-02-09  |  3.4 KB  |  62 lines
  1.  
  2.                    Program information for KeyChange
  3.                    =================================
  4.  
  5. Most of the module code is fairly standard. Entries are provided for
  6. initialisation, finalisation, service calls (Service_Reset only), and a
  7. single command *KeyChange.
  8.  
  9.   The initialisation code claims workspace and zeroes it. It then
  10. initialises some state flags, and passes the command tail to the code that
  11. deals with the *KeyChange command, to allow the initial mode to be set. All
  12. of this is only done for a real initialisation, i.e. not after *RMTidy.
  13.  
  14.   The rest of the code is executed for any initialisation, and also on a
  15. Service_Reset (as reset releases all claimed vectors). The key state flags
  16. are all cleared to zero (i.e. not pressed), the event vector and buffer
  17. insert vector are claimed, and the key up/down event is enabled. Finally,
  18. the keypad mode is set to reflect the state of the Num Lock key.
  19.  
  20.   The finalisation code disables the key up/down event, and releases the
  21. vectors. On a permanent finalisation the workspace is released.
  22.  
  23.   Despite being rather long, the * command code is very simple. If there are
  24. no parameters the current status is printed out using embedded strings.
  25. Otherwise the parameters are parsed, and result in the setting or clearing
  26. of mode flags. The commands which change the keypad mode also have to deal
  27. with the Num Lock state.
  28.  
  29.   The key up/down code maintains the state of keys in which it's interested,
  30. as it's not clear if the "scan keyboard" OS_Bytes can be called from
  31. interrupt code. The module contains a table with a byte for each possible
  32. keycode; this is either &FF for "not interesting", or a workspace offset in
  33. which to store the state (1=down, 0=up). Further processing is done for the
  34. Shift, Ctrl and Alt keys, to merge the left and right keys into a single
  35. flag (0=neither pressed). The right-hand Ctrl key is treated as either a
  36. Ctrl or an Alt depending on the ctrlon status.
  37.  
  38.   If the padon flag is set, the Num Lock key is also treated specially. This
  39. code deals with the interaction between Num Lock (with Shift or Ctrl) and
  40. the keypad mode. Note that curmode stores the current mode, lastmode the
  41. last Num Lock on mode (1, 3 or 4), and padmode the selected "special" mode
  42. (3 or 4).
  43.  
  44.   Unless mode 2 is being selected, the Num Lock state is forced on. Because
  45. the relevant OS_Bytes aren't re-entrant, this is done with a CallBack.
  46. However, it appears that the keyboard handler also changes the Num Lock
  47. state with a CallBack, and moreover the order in which the two CallBacks are
  48. executed is not always the same. Thus OS_CallAfter is used to interpose a
  49. 100 msec delay, which seems to be sufficient.
  50.  
  51.   The heart of the code is the routine called on buffer insertion. It
  52. maintains a flag for characters preceded by a null, as these are top-bit-set
  53. characters and must be passed unchanged. Otherwise, if the character is >=
  54. &80 and the exton flag is non-zero, the code is modified according to the
  55. status of the alt/ctrl keys, and then passed on (see the PRM chapter on
  56. vectors for more details). If the padon flag is non-zero and the keypad mode
  57. is 3 or 4 codes < &80 are checked (using a lookup table for non-numeric
  58. keys) to see if they are keypad keys; this involves looking at the stored
  59. state flags, to distinguish the keys on the keypad from those on the main
  60. keyboard with the same buffer codes. If appropriate the codes are again
  61. modified to generate the relevant function key code before being passed on.
  62.